/*
 ***************************************************************************************
 * 
 * @Title:  SlicedBlock.java   
 * @Package io.github.junxworks.junx.stat.datawindow.timewindow   
 * @Description: (用一句话描述该文件做什么)   
 * @author: Michael
 * @date:   2018-7-12 20:49:28   
 * @version V1.0 
 * @Copyright: 2018 JunxWorks. All rights reserved. 
 * 
 *  ---------------------------------------------------------------------------------- 
 * 文件修改记录
 *     文件版本：         修改人：             修改原因：
 ***************************************************************************************
 */
package io.github.junxworks.junx.stat.datawindow;

import io.github.junxworks.junx.stat.datawindow.timewindow.ExpirableObject;

/**
 *  为什么要切分时间窗口？因为没有必要缓存（存储）每一条统计数据，目前统计数据是缓存在Redis集群中的，
 *  试想，在一个长度周期为5天（或者更长）的统计定义中，用户每一条统计相关数据都会被缓存在redis中，
 *  这不仅增加了网络传输压力，更浪费了redis宝贵的内存空间，因此要对时间窗口进行切分统计。
 *	对统计时间窗口内部集合进行切分，通常一个大的时间窗口，内部会被切分成小的时间窗口（SlicedBlock切分块），
 *  每个切分块本质上也是一个时间窗口，每个切分块对象都会有一个过期时间expireTime、过期时间点expireTimePoint和
 *  领跑时间pacemakerTime（下方解释），切分块是时间窗口内部的最小存储对象，统计数据到来后，会被累计到切分块中，
 *  所有切分块的累计值，才是这个统计的实际值。时间窗口在滑动的时候，让时间窗口滑动基于切分块来滑动，而不是整个
 *  窗口一次性往前滑动整个窗口，因此不会造成因为时间窗口的滑动导致统计数据误差太大。例如一个5分钟的时间窗口，
 *  我们会切分成5个一分钟的切分块，时间窗口是1分钟一分钟的滑动，这样每次滑动仍然会保留4分钟的数据。我们以策略的
 *  方式向外提供窗口切分规则(sliceStrategy)，策略可以有多种实现。
 *  
 *  注释：领跑时间本质上是一个时间窗口的最大时间，和窗口的过期时间点对应，两个值决定了时间窗口的宽度。
 *  目前我们以接收到最近交易事件所在的切分块的最大时间点，作为时间窗口滑动的领跑时间，促使时间窗口产
 *  生切分块的事件我们可以称为领跑事件（pacemakerEvent），领跑事件所在的切分块的最大时间，为当前时间窗口的领跑时间。
 *  
 *  过期时间点，决定了当前时间窗口内的数据何时过期，跟领跑时间对应，这两个值决定了时间窗口宽度。
 *  
 *   注意：切分块在时间窗口内部是非连续的，是根据交易事件的发生时间动态切分的，每个切分块的时间宽度不一定是一样的，是根据窗口定义的单位动态计算出来的。

 *
 * @author: Michael
 * @date:   2017-5-19 16:25:03
 * @since:  v1.0
 */
public interface SlicedBlock extends ExpirableObject, TimeBasedDataWindow {

}
